temp. tabulka

Otázka od: Robert TOTH

30. 9. 2002 7:13

Je nejaka moznost vytvorenia temporalnej tabulky v Firebirde ?
Potrebujem spustit query (filter), nasledne spustat dalsie rozne
query(analyzy), kt. vybera hodnoty len pre zaznamy z query predosleho,
sposob master-detail mi nevyhovuje, lebo hlada len pre aktualny zaznam.
Moznost spojenia cez cyklovanie pomocou SELECT * ... IN () sa mi zda
tazkopadne. Pozeral som DSQL prikazy ale nemam s nimi vela skusenosti. Dalsi
problem je v tom, ze tato tabulka (temporalna), alebo "cursor" by mala byt
zrusena serverom pri odpojeni.

Ing. Robert TOTH
Lucenec

Odpovedá: Peter Brcko

30. 9. 2002 17:11

> Je nejaka moznost vytvorenia temporalnej
> tabulky v Firebirde ?
> Potrebujem spustit query (filter), nasledne
> spustat dalsie rozne
> query(analyzy), kt. vybera hodnoty len pre
> zaznamy z query predosleho,
> sposob master-detail mi nevyhovuje, lebo hlada
> len pre aktualny zaznam.
> Moznost spojenia cez cyklovanie pomocou SELECT
> * ... IN () sa mi zda
> tazkopadne. Pozeral som DSQL prikazy ale nemam
> s nimi vela skusenosti. Dalsi
> problem je v tom, ze tato tabulka
> (temporalna), alebo "cursor" by mala byt
> zrusena serverom pri odpojeni.
>
> Ing. Robert TOTH
> Lucenec
>
>
>
>

Pokial je to QUERY(filter) rovnake pre urcite prehlady,
je to zrele na VIEW v databaze.
Na tento view budete spustat dalsie analyzy.

--------------------------------------------
Ing. Peter Brcko
SoftProjekt s. r. o.
Komenského K-11
069 01 Snina
tel., fax +421 57 762 5395, +421 57 762 3645
pbr@softprojekt.sk; (priv) pbr@post.sk
--------------------------------------------

________
Prva Pomoc, Srandicky, Hry, Hudba, Zoznamenie, Erotika, ...
http://www.post.sk/forum/

Odpovedá: Peter Brcko

30. 9. 2002 16:50

Odpovedá: Jan Sebelík

1. 10. 2002 16:03

> Odesílatel: Robert TOTH <toth@lc.vszp.sk>
> Je nejaka moznost vytvorenia temporalnej tabulky v Firebirde ?
> Potrebujem spustit query (filter), nasledne spustat dalsie rozne
> query(analyzy), kt. vybera hodnoty len pre zaznamy z query predosleho,

Obecne jsem toho nazoru, ze pokud vznika nutnost vytvaret pomocne tabulky,
signalizuje to, ze databaze je spatne navrzena. V dobre navrzene databazi
vystaci (nekdy slozity) select.

I pri spatne navrzene databazi ale stale ale existuje lepsi cesta, nez pomocne
tabulky.
Pouzij ulozenou proceduru, ktera v dilcim "for select ..." bude provadet dalsi
vypocty. Bude to mozna navic rychlejsi, nez nejaky sileny select.

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Ing. Marek Kocan

1. 10. 2002 17:52

ahoj Honzo,
----- Original Message ----- >
> Obecne jsem toho nazoru, ze pokud vznika nutnost vytvaret pomocne tabulky,
signalizuje to, ze databaze je spatne navrzena. V dobre navrzene databazi
vystaci (nekdy slozity) select.
>

nerekl bych, TT muze byt vhodna napriklad z duvodu zrychleni analytickych
vypoctu, kdy si data predpripravis a pak z nich delas nekolik selektu... Jde
to pochopitelne resit klasikou tabulkou, ale je to narocnejsi na spravu...
Takze mozne reseni jsou v FB prave klasicke tabulky a jejich mazani,
pripadne hlidani dalsim specialnim uzivatelem, ktery na zaklade stavove
informace tuto tabulku rusi...

Mej se a vsichni tez. KER

Odpovedá: Martin Schayna

1. 10. 2002 17:58

----- Original Message -----
From: "Tom Beran" <assas@bonbon.net>
> > I pri spatne navrzene databazi ale stale ale existuje lepsi
> > cesta, nez pomocne tabulky. Pouzij ulozenou proceduru, ktera
>
> Da se nejak, dle vaseho nazoru, rozumne resit bez pomocnych tabulek (at uz v
databazi ci v pameti) situace, kdyz mam objektove zalozenou, v UML modelovanou,
aplikaci. Objekty jsou dvou zakladnich druhu - reprezentuji bud jeden record
nebo recordset (zjednodusene receno, ten recordset je, de facto, lajdacka
realizace kolekce objektu), podle toho, jaky druh vazby je treba modelovat
(1:1, 1:N, M:N-no, to uz je ovsem asociativni trida). Objekty mohou agregovat
hafo dalsich objektu (obou dvou typu). Pokud se edituje nejaky komplikovany
objekt, ktery agreguje hromadu dalsich, chce se, aby se zmeny cele slozite
struktury promitly v databazi az v okamziku, kdy zavolam Save na hlavnim
objektu.
> Tohle snad ani bez pomocnych tabulek resit nelze?
>

Edituj to cele v pameti a uloz jako sekvenci insertu a updatu.
To ovsem predpoklada business objektovy framework.
Martin Schayna

Odpovedá: Tom Beran

1. 10. 2002 16:42

> Obecne jsem toho nazoru, ze pokud vznika nutnost vytvaret
> pomocne tabulky, signalizuje to, ze databaze je spatne
> navrzena. V dobre navrzene databazi vystaci (nekdy slozity) select.
>
> I pri spatne navrzene databazi ale stale ale existuje lepsi
> cesta, nez pomocne tabulky. Pouzij ulozenou proceduru, ktera

Da se nejak, dle vaseho nazoru, rozumne resit bez pomocnych tabulek (at uz v
databazi ci v pameti) situace, kdyz mam objektove zalozenou, v UML modelovanou,
aplikaci. Objekty jsou dvou zakladnich druhu - reprezentuji bud jeden record
nebo recordset (zjednodusene receno, ten recordset je, de facto, lajdacka
realizace kolekce objektu), podle toho, jaky druh vazby je treba modelovat
(1:1, 1:N, M:N-no, to uz je ovsem asociativni trida). Objekty mohou agregovat
hafo dalsich objektu (obou dvou typu). Pokud se edituje nejaky komplikovany
objekt, ktery agreguje hromadu dalsich, chce se, aby se zmeny cele slozite
struktury promitly v databazi az v okamziku, kdy zavolam Save na hlavnim
objektu.
Tohle snad ani bez pomocnych tabulek resit nelze?

Tom

Odpovedá: Petr Fejfar

2. 10. 2002 13:40

From: "Jan Sebelík" <honza@haes.cz>

> Obecne jsem toho nazoru, ze pokud vznika nutnost
> vytvaret pomocne tabulky, signalizuje to,
> ze databaze je spatne navrzena. V dobre navrzene
> databazi vystaci (nekdy slozity) select.

A jak se tedy resi napr. obycejny browser na webu,
kdy pomoci selectu vyberes mnozinu zaznamu usporadanou podle nejaky kriterii
a chces ji zobrazovat po strankach vpred/vzad.

Tam Ti asi nezbyde nez priradit kazdemu zaznamu
poradove cislo, abys mohl pri dalsim requestu
navazat na predchozi stranku

***

Co jsem slysel od databazistu z non-PC platforem,
tak se k tomu pouzivaji prave nejake "renderovaci" tabulky.

pf

Odpovedá: Kalus Jozef Ing.

2. 10. 2002 14:20

A jak se tedy resi napr. obycejny browser na webu,
kdy pomoci selectu vyberes mnozinu zaznamu usporadanou podle nejaky kriterii
a chces ji zobrazovat po strankach vpred/vzad.

PHP ma na to svoje funkcie

jednoducho urobis SELECT a potom si zoberies
iba dany pocet v cykle ako napr takto:

while ($zoznam=MySQL_Fetch_Array($OK_ZOZNAM)):
$cykl++;
if (($cykl>=$pocet_cykl_od) && ($cykl<=$pocet_cykl_do)):

a tu je akcia, a kedze sa to deje na serveri naspat (do html)
dostanes iba n konkretnych zaznamov, ale to si myslim ze je OT a ak chcel
mozem ti poslat zdrojaky stranke www.equipment.sk aby si sa na to mohol
mrknut ale to mimo konf.

joka

Odpovedá: Petr Fejfar

2. 10. 2002 15:27

From: "Kalus Jozef Ing." <jozef.kalus@spordat.sk>

> PHP ma na to svoje funkcie jednoducho urobis
> SELECT a potom si zoberies
> iba dany pocet v cykle ako napr takto:

Pokud tomu rozumim, tak vzdy sestavis vyslednou
mnozinu znovu selectem a v ni naleznes zaznamy,
ktere chces zobrazit.

Predpokladam, za takto plytvat vykonem by umel kazdej
a nemusi mit k tomu ani PHP

Me jde o nejake sofistikovanejsi reseni...

Bye, pf

Odpovedá: Kalus Jozef Ing.

2. 10. 2002 16:49

Predpokladam, za takto plytvat vykonem by umel kazdej
a nemusi mit k tomu ani PHP

Me jde o nejake sofistikovanejsi reseni...

ako vidim nevsimol si si vetu ze je to robene na serveri, ale tvoje riesenie
omnoho viac zatazuje komunikaciu klient server, skus si niekde precitat
nieco o db serveroch a optimalizacii, napr. pre ORACLE ( a to uz je riadna
DB) je vyhodnejsie mu to dat urobit na serveri ako komunikovat dlhsie
klient-server (ups... to ste vedeli ze ORACLE kient vzdy caka na odozvu
servera ? jednoducho nieco posle a caka na potvrdenie ze to naozaj na server
doslo

, ono nie vzdy na prvy pohlad horsie riesenie je v konecnom
dosledku naozaj horsie, inak kazda DB si robi naskor nejaky plan podla
ktoreho vybera z db fajlov prislusne data (tu je vlastne cele sranda okolo
indexov) a nie vzdy je dany plan naozaj optimalny, nie vzdy je index vyhrou,
napriklad v mojom priklade ide o full scan co je zapichnutie sa diskovej
hlavicky a precitanie tabulky jednym vrzom (db sa snazi ukladat sekvencne na
disk aby bola vykonnejsia pri citani), co sa tyka tvojho riesenia, musis
najskor vytvorit tabulku, nacitat data (mozno pouzit indexy - haha a je po
full scane - pretoze musi hlavicka skakat ako diva po disku) a potom ich
zase ulozit niekde ( ozaj ukladanie byva zvycajne dlhsie ako citanie -
napriklad robi indexy ) no a teraz este len zacnes citat, a pravdaze ked
chces nejaky interval, tak mas zase dve moznosti: Full scan (to si sa prave
dostal tam kde som bol ja hned na zaciatku

) alebo index... a to sa zase
riadne zdrzi server, ked si tie mozno milisekundicky spocitas na serveri a
potom milisekundicky na komunikaciu... tak sa zhrozis ze ti vychadzaju
radovo riadne sekundy... alebo pri vacsich tabulka desiatky sekund...az
hodiny

je to divne ale je to tak...

uffff... dufam ze admin sa na mna nenastve

ale musel som to zo seba
dostat

joka

PS: mam pred sebou biflu zo skolenia optimalizacie DB

Odpovedá: Tom Beran

2. 10. 2002 17:16

>A jak se tedy resi napr. obycejny browser na webu,
>kdy pomoci selectu vyberes mnozinu zaznamu usporadanou podle nejaky kriterii
>a chces ji zobrazovat po strankach vpred/vzad.
>
>Tam Ti asi nezbyde nez priradit kazdemu zaznamu
>poradove cislo, abys mohl pri dalsim requestu
>navazat na predchozi stranku
>

No, mam pocit, ze kdyz jsem cosi programoval v PHP nad MySQL, tak tam se dalo
primo v SELECTu rict, ze chcu zaznamy M az N a nic vic se neresilo ... takze to
zalezi na DBSM ... pokud to potrebuji pro DBSM (treba MSSQL, ktery umi jen TOP
N), ktery to neumi, musim si ocislovat zaznamy a SELECTovat podle cislovani
(hmm, a ze bychom byli opet u neprerusene ciselne rady

Odpovedá: Petr Fejfar

2. 10. 2002 16:43

From: "Kalus Jozef Ing." <jozef.kalus@spordat.sk>

> ako vidim nevsimol si si vetu ze je to robene
> na serveri, ale tvoje riesenie
> omnoho viac zatazuje komunikaciu klient server,

Jak to? Jestli to cele nechapu spatne (myslim ze ne), tak ty
"renderovaci
tabulky" jsou taky na serveru a plni se nejakym commandem stylu

    INSERT INTO ..... SELECT ....

a ten snad proboha s komunikaci klient-server nema vubec nic spolecneho...
nebo ma ?!

> full scane - pretoze musi hlavicka skakat
> ako diva po disku)

Ja bych to s tim skakanim hlavicky nevidel tak cerne

a) na ceste sector na disku -> buffer v aplikaci
    je nekolik ruznych cache pameti s kapacitou
    radove desitek MB, takze casto se hlava nemusi
    pohnout vubec

b) pokud Tvuj full scan na live datech bude
    do DB, ktera je alespon ve 3NF a ten dotaz nebude
    zrovna trivialni, tak tam bude tolik joinu mezi
    tabulkama, ze hlavicka by skakala stejne jako diva

Bye, pf

Odpovedá: bleak

4. 10. 2002 11:05

MySql má volbu LIMIT, ktera toto umoznuje...nic se necisluje...
SELECT * FROM t1 ORDER BY f1 LIMIT 15,10
je to velmi rychle...

> A jak se tedy resi napr. obycejny browser na webu,
> kdy pomoci selectu vyberes mnozinu zaznamu usporadanou podle nejaky
kriterii
> a chces ji zobrazovat po strankach vpred/vzad.

???

> Co jsem slysel od databazistu z non-PC platforem,
> tak se k tomu pouzivaji prave nejake "renderovaci" tabulky.

Odpovedá: Jan Sebelík

2. 10. 2002 22:33

> Odesílatel: Petr Fejfar <development@callnet.cz>
> A jak se tedy resi napr. obycejny browser na webu,
> kdy pomoci selectu vyberes mnozinu zaznamu usporadanou podle nejaky kriterii
> a chces ji zobrazovat po strankach vpred/vzad.
To jsme resili pomoci COM-objektu, který nejaky cas vytvorena data drzel a pak
se evetualne zrusil.
Podotykam, ze to nebylo v Delphi a ze to nebylo nad relacni databazi.
Ostatne, kdo zrusi ty temp tabulky, kdyz klient uz dalsi data nechce?

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Jan Sebelík

2. 10. 2002 23:03

> > From: "Tom Beran" <assas@bonbon.net>
> > Da se nejak, dle vaseho nazoru, rozumne resit bez pomocnych tabulek (at uz
v databazi ci v pameti) situace, kdyz mam objektove zalozenou, v UML
modelovanou, aplikaci.

> Odesílatel: Martin Schayna <mschayna@aktis.cz>
> Edituj to cele v pameti a uloz jako sekvenci insertu a updatu.
> To ovsem predpoklada business objektovy framework.

Jasne. Treba COM-objekty.

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Jan Sebelík

2. 10. 2002 23:19

> Odesílatel: Ing. Marek Kocan <kocan@ebchod.cz>

> > Honza
> > Obecne jsem toho nazoru, ze pokud vznika nutnost vytvaret pomocne tabulky,
> signalizuje to, ze databaze je spatne navrzena. V dobre navrzene databazi
> vystaci (nekdy slozity) select.

> nerekl bych, TT muze byt vhodna napriklad z duvodu zrychleni analytickych
> vypoctu, kdy si data predpripravis a pak z nich delas nekolik selektu...

Vysledkem analytickych vypoctu je "cosi", na co se zapomnelo pri datove
analyze.
Proto to chybi ve "standardnich" tabulkach a zada si to "temporary".

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Ing. Marek Kocan

4. 10. 2002 15:20

ahoj Honzo,
> > nerekl bych, TT muze byt vhodna napriklad z duvodu zrychleni
analytickych
> > vypoctu, kdy si data predpripravis a pak z nich delas nekolik selektu...
>
> Vysledkem analytickych vypoctu je "cosi", na co se zapomnelo pri datove
analyze.
> Proto to chybi ve "standardnich" tabulkach a zada si to "temporary".
>
opet bych nerekl, analyticke pozadavky se mohou vcelku opravnene v prubehu
existence systemu menit (dostavame se napriklad k ad-hoc dotazum). Obdobne
to plati za situace, kdy by bylo nerozumne drzet v databazi data pro vypocty
provadene treba jen jednou za mesic, za rok... Aby nedoslo k omylu, nema to
smysl pro desitky mega, ale pro hranici gigabajtovych databazi jiz ano.
Rozdily ve vykonu jsou znacne. Obecne si myslim, ze TT je vhodna prave za
ucelem vyreseni problemu s vykonem, s pri analyze presne nezjistitelnymi
stavy (a ze jich je - to neni chyba analytika, nektere stavy a procesy
proste nejdou podhytit), s v diskusi jiz zminemi predpripravenymi vysledky -
napriklad pro prezentaci na webu. Jako vzdy se ale i tyto problemy daji
resit jinak, TT jsou jen jednou z moznosti - ve vetsine pripadu IMHO
spravnou. A troufam si rici, ze ve vsech tridach architektury C/S, tedy i
pro trivrstve aplikace.

Navic si myslim, ze zacina jit o pomerne akademickou diskusi. IB/FB TT
nepodporuje, jak jsem psal, moznym resenim jsou klasicke tabulky a jejich
hlidani dalsim procesem/uzivatelem, ale je na zvazenou, zda se to vyplati.
Zalezi proste na kazde konkretni situaci.

Pokud bychom totiz obecne pripustili, ze TT je nevhodne reseni, muzeme
stejnym zpusobem sepsout pohledy... ty take nejsou pro mnoho veci idealni a
de-facto jsou bohuzel velmi casto pouzivany pro vylepseni datoveho modelu.
Bohuzel si malo lidi za takove situace uvedomuje, ze se jedna jen o predpis,
ktery stejne vede ke slozitemu dotazu. Ale jsou mist,a kde jsou pohledy
naprosto opravnenou zalezitosti - napriklad pri slozitem Unionu apod...

KER

Odpovedá: Petr Fejfar

4. 10. 2002 11:27

From: "Jan Sebelík" <honza@haes.cz>

> To jsme resili pomoci COM-objektu,
> který nejaky cas vytvorena data drzel
> a pak se evetualne zrusil.

Na pozadi meho prispevku bylo, ze jsem se kdysi
ptal renomovaneho datare, jak se takova vec resi
v DB svete a jeho odpoved byla, ze zpravidla
pomocnou tabulkou. No a ty pises, ze uziti temporary
tabulek znaci chybny navrh DB.

Tak si to chci jako "nedatar" ujasnit, protoze se mi zda, ze ve svete DB je
vsechno naruby.

BTW, jak bys to teda resil bez uziti COMu?

***

> Ostatne, kdo zrusi ty temp tabulky,
> kdyz klient uz dalsi data nechce?

a) _Kazdy_ server, ktery jsme dosud resili,
mel automaticky "house-keeping"
b) _Vetsina_ zakazniku takovy "house-keeping"
stejne pozaduje

***

Pravdu mas v tom, ze ta tabulka nemusi mit charakter
temporary tabulky ve smyslu transience zivotniho
cyklu, ale muze existovat trvale -> jeji existence
je tudiz vysledkem analyzy

,
ale IMHO jeji funkce je implementacni (kompenzuje insuficienci SQL serveru)
a nikoli logicka
a tudiz se jedna o pomocnou tabulku. Neplatne
zaznamy by se odstranovali rovnez v ramci
house-keepingu.

Takze hlavni otazkou zrejme je, jak uzce/siroce chapeme pojem temporary
table - jestli jako terminus technicus ze sveta SQL serveru nebo obecneji
jako "pomocnou tabulku", jejiz existence neplyne z aplikacni logiky.

Bye, pf

Odpovedá: Peter Vlkovic

4. 10. 2002 14:46

> No, mam pocit, ze kdyz jsem cosi programoval v PHP nad MySQL,
> tak tam se dalo primo v SELECTu rict, ze chcu zaznamy M az N...

sluzi na to klauzula LIMIT:

LIMIT [offset,] rows

offset - od ktoreho zaznamu sa data zobrazuju,
rows - pocet zobrazovanych zaznamov.

Vlkovic

Odpovedá: Petr Fejfar

4. 10. 2002 13:12

From: "Jan Sebelík" <honza@haes.cz>

> Vysledkem analytickych vypoctu je "cosi",
> na co se zapomnelo pri datove analyze.
> Proto to chybi ve "standardnich" tabulkach
> a zada si to "temporary".

Dovolim si nesouhlasit: mame serverovou aplikaci,
ktera produkuje transakcni journal tj.
v podstate DB tabulku, kde kazdy radek odpovida jedne transakci.

Vedle toho existuji "stada" ruznych manageru
na ruznych urovnich, ktere zajima kazdou chvili
neco jineho - zpravidla jsou to ruzne zavislosti
a statistiky vypovidajici o charakteru provozu
tj. funkce v ramci MIS, napr. jak se zmenil pomer muzu/zen vlivem reklamy v
TV nebo zda je narust zakazniku vysledkem .... atd. Mnozina takovych
pozadavku je tudiz otevrena.

***

Takze IMHO pro MIS plati, ze se nemohou pri porizovani dat tj. dopredu
agregovat ruzna data tak, aby usnadnila vetsinu pozdejsich statistickych
vypoctu.

Zpravidla je soucasti zadani nejaka relativne
mala mnozina zakladnich statistik,
ktere se pocitaji in-line, zbytek se resi
off-line zpravidla mimo projekt jako rozsireni funkci MIS, casto uplne
jinym, specializovanym teamem.

IMHO nemoznost agregovat data dopredu plati obecne, protoze statistik
pracuje tak, ze zformuluje hypotezu, vybere odpovidajici metody jak ji
potvrdit/vyvratit,
z teto metody vyplyne, jaka data bude potrebovat
a jde pocitat a nejspis pri tom pouziva
pomocne tabulky

Bye, pf

Odpovedá: Petr Palicka

4. 10. 2002 9:59

ahoj,

nejsem si uplne jisty vyznamem TempTabulek,
ale myslim si, ze takove view, nebo "pracovni"
tabulka (kdy si nejakym klicem hlidam komu veta
patri) _ma_ svuj vyznam.
hlavne je to na akademickou diskusi (treba u
piva v Belohrade

. Urcite ma smysl, mit pro
sestavu, ktera je potreba jednou cas (ale je
potreba), mit nejaky podobny udelatko prichystany.

dekuji

peca

ps: bohuzel mi nejak v praci blbne pop3, takze
nemam vsecky majly, proto se omlouvam, pokud
mluvim z cesty, nebo odpovidam na z kontextu
vytrzeny mejl, nebo na jiny neodpovim...

Odpovedá: Lstiburek Pavel

4. 10. 2002 9:44

> Od: Jan Sebelík [mailto:honza@haes.cz]
> > Odesílatel: Ing. Marek Kocan <kocan@ebchod.cz>
>
> > > Honza
> > > Obecne jsem toho nazoru, ze pokud vznika nutnost vytvaret
> pomocne tabulky,
> > signalizuje to, ze databaze je spatne navrzena. V dobre
> navrzene databazi
> > vystaci (nekdy slozity) select.
>
> > nerekl bych, TT muze byt vhodna napriklad z duvodu
> zrychleni analytickych
> > vypoctu, kdy si data predpripravis a pak z nich delas
> nekolik selektu...
>
> Vysledkem analytickych vypoctu je "cosi", na co se zapomnelo
> pri datove analyze.
> Proto to chybi ve "standardnich" tabulkach a zada si to "temporary".

SELECT SQL je velice mocny, ale komplikovane dotazy jsou casto velmi, velmi
pomale a TT casto dokaze zrychlit vypocet nebo dotaz i o nekolik radu. Dalsi
dobrou vlastnosti je zvyseni prehlednosti - algoritmus lze rozdelit do
jednoduchych kroku. Myslim si, ze kazdy uz se nekdy vratil od "elegantniho"
SELECT k nekolika jenodusim prikazum insert, update, delete, protoze byly
sice "osklive", ale velmi rychle.

Pavel

Odpovedá: Erik Salaj

4. 10. 2002 11:10

>> nerekl bych, TT muze byt vhodna napriklad z duvodu zrychleni analytickych
>> vypoctu, kdy si data predpripravis a pak z nich delas nekolik selektu...
>
>Vysledkem analytickych vypoctu je "cosi", na co se zapomnelo pri datove
analyze.
>Proto to chybi ve "standardnich" tabulkach a zada si to "temporary".

niektore udaje nie je potrebne ukladat do "standarnych" tabuliek, ak je
mozne
ziskat ich z inych udajov vypoctom. Vysledkom dobrej analyzy by nemali byt
neopodstatnene redundantne udaje v tabulkach. Ak je ale ten vypocet
komplikovany,
tak moze byt vyhodnejsie ulozit vysledky do pomocnej tabulky s moznostou
vyuzit ich viackrat bez opakovaneho vypoctu - cize je to vec optimalizacie
a nie zlej datovej analyzy.

Erik

Odpovedá: Ludo Fulop

4. 10. 2002 13:04

> > tak tam se dalo primo v SELECTu rict, ze chcu zaznamy M az N...
> sluzi na to klauzula LIMIT:
> LIMIT [offset,] rows

Access (2000) LIMIT nepozna, da sa v nom vyselektovat napr. N-ty zaznami
inak?

Ludo Fulop

Odpovedá: Kalus Jozef Ing.

4. 10. 2002 11:48

bavili sme sa ako sa to robi na inete, predpokladam ze na inet nebudes mat
sialene joiny cez 3 a viac tabuliek alebo ano (pri nejakom vyberani clankov
a ich strankovani snad nie)?

to co som pisal s milisekundami si treba uvedomit na velkych DB, ono to nie
je az take ruzove s tymi buframy ako pises a naozaj to nie je zanedbatelne,
kolegovia to skusali na Oracle a to mali satelitne spojenie (oneskorenia cca
milisekundy) a tam bola odozva naozaj niekolko nasobna prave koli tymto
zdrzaniam,

uznavam, ze zalezi na danej tabulke a jej velkosti... ale vzdy je dobre sa
zamysliet nad tym ako to ten server bude fyzicky robit, ked sa chces venovat
vykonu, inak ti to moze byt jedno ci raz za 10 minut prerves cely select cez
tabulku alebo nie...

ja som len chcel upozornit ze aj sofistikovanejsie riesenie moze byt horsie
ako nejake na prvy pohlad "blbe" riesenie

joka

-----Original Message-----
From: Petr Fejfar [mailto:development@callnet.cz]
Sent: Wednesday, October 02, 2002 4:59 PM
To: delphi-l@clexpert.cz
Subject: Re: temp. tabulka

From: "Kalus Jozef Ing." <jozef.kalus@spordat.sk>

> ako vidim nevsimol si si vetu ze je to robene
> na serveri, ale tvoje riesenie
> omnoho viac zatazuje komunikaciu klient server,

Jak to? Jestli to cele nechapu spatne (myslim ze ne), tak ty
"renderovaci
tabulky" jsou taky na serveru a plni se nejakym commandem stylu

INSERT INTO ..... SELECT ....

a ten snad proboha s komunikaci klient-server nema vubec nic spolecneho...

Odpovedá: Jan Sebelík

4. 10. 2002 11:46

> Odesílatel: Petr Fejfar <development@callnet.cz>
> pomocnou tabulkou. No a ty pises, ze uziti temporary
> tabulek znaci chybny navrh DB.
>
> Tak si to chci jako "nedatar" ujasnit, protoze se mi zda, ze ve svete DB je
> vsechno naruby.

Moje stanovisko proti temp tabulkam bylo vyjadreno asi moc kategoricky.
Mohl slevit asi takto:
-
Cim lepsi datovy navrh, tim mensi potreba vytvaret pomocne tabulky.
-
A naopak, pokud se uz predem smirim s beznym pouzivanim pomocnych tabulek,
odvadi to pozornost od pozadavku na opravdu precizni datovy navrh.
"Vzdyt my z te databaze ta data nejak vyzdimeme, udelame si pomocnou tabulku a je to ..."
-
Pokud jde o web, vymysleli jsme si vlastni (objektove orientovanou) databazi,
ktera prave podporuje s webem spojene pozadavky (viz www.ebyznys.cz a muj
prispevek na seminari Delphi2001). Nad moznostmi, ktere v tomto smeru poskytuji
nebo neposkytuji "standardni" databaze, jsem proto prilis nepremyslel. Bohuzel,
uz nam chybely sily, abychom tu databazi dotahli do stavu umoznujiciho obecne
pouziti.

Honza
=========================================
= HAES - RNDr. Jan Sebelik
= http://www.haes.cz
= Skolici a konzultacni stredisko pro Delphi a Win32
= Vojtiskova 206
= 507 81 Lazne Belohrad
= tel. 493 792 931 (mobil 776 347735)
=========================================

Odpovedá: Ludek ZITA

7. 10. 2002 0:37

----- Original Message -----
From: "Jan Sebelík" <honza@haes.cz>
> Pokud jde o web, vymysleli jsme si vlastni (objektove orientovanou)
databazi,
> ktera prave podporuje s webem spojene pozadavky (viz www.ebyznys.cz a muj
> prispevek na seminari Delphi2001). Nad moznostmi, ktere v tomto smeru
> poskytuji nebo neposkytuji "standardni" databaze, jsem proto prilis
nepremyslel.
> Bohuzel, uz nam chybely sily, abychom tu databazi dotahli do stavu
umoznujiciho obecne pouziti.

Ahoj.
Skoda.
Jinak podle mne nejlepsi DB pro web je MySQL.
Vyhody vidim v "cene", v rychlosti , nizkych narocich na vykon serveru a v
dobre vyresenych moznostech pristupu k ni (PHP,ODBC...)

Ludek

Odpovedá: Petr Fejfar

8. 10. 2002 13:16

From: "Kalus Jozef Ing." <jozef.kalus@spordat.sk>

> bavili sme sa ako sa to robi na inete,

protoze web je nejtypictejsim predstavitelem tridy
uloh, kdy DB client neni celou dobu on-line
a potrebuje se vracet k nejakemu vysledku.

> predpokladam ze na inet nebudes mat sialene
> joiny cez 3 a viac tabuliek alebo ano
[...]
> uznavam, ze zalezi na danej tabulke
> a jej velkosti... ale vzdy je dobre sa

Clovece, z Tveho mailu mam pocit, ze nemluvime
o relacni DB ale o nejake flat tabulce

Kdyz vezmu napr. obycejny katalog firem, tak
tam tech tabulek bude namatkou hned nekolik:
firma, obec, obory podnikani, telefony, referenti
+ relacni tabuky (firma zpravidla podnika v nekolika oborech, rada firem ma
vice telefonu, vice referentu, vice sidel atd.).
A podobne to bude s celou radou aplikaci, ktera me napada a lze ji na NETu
potkat :-O

> ja som len chcel upozornit ze aj sofistikovanejsie
> riesenie moze byt horsie ako nejake na prvy pohlad
> "blbe" riesenie

Ano, muze. Kazda implementacni technika ma nejakou oblast optimalniho
nasazeni a marginalni pripady
je treba individualne posuzovat - ale prave
z takoveho pohledu je IMHO oblast pouziti
"renderovacich" tabulek daleko sirsi nez proste opakovani dotazu.

Navic z pohledu celeho zivotniho cyklu aplikace
je IMHO jeste vyznamnejsi, ze overhead spojeny s renderovacimi tabulkami je
nezavisly na typu dotazu,
takze pripadne dalsi pozadavky na slozitost dotazu
aplikaci neodsoudi k rekonstrukci ci do zahuby.

pf

Odpovedá: Martin Kleiner

10. 10. 2002 12:57

Pri cteni prispevku na toto tema se nestacim divit.

Kvuli tomu, ze IB/FB nema temp.tables, nejsou automaticky spatne.

Jsou pripady, kdy TT je idealni reseni, co do rychlosti i spravy DB,
Napriklad tehdy, pokud uzivatel potrebuje pracovat se statistickymi daty
(to znamena ze vybrane udaje tridi, filtruje, grupuje, sumuje atd...).

Zajimalo by me take, kdo z lidi, kteri v teto diskusi odsuzuji
"temporary
tables" nekdy vytvoril a spravuje velkou databazi s radove GB dat,
se kterou
soucasne pracuji desitky uzivatelu (z nichz nekteri vyuzivaji pro praci
statisticke udaje), a kdo je teoretik typu "Brouk Pytlik".

A pokud mu takova databaze bezi na IB/FB, tak je sebevrah, nebo se nikdy se
nesetkal s uzivatelem, ktery na teto DB musi pracovat
(mluvim o stabilite DB, odezve pri vice uzivatelich, administraci, moznosti
SQL jazyka atd...).

Martin Kleiner

>>>----- Original Message -----
>>>From: "Jan Sebelík" <honza@haes.cz>
>>>
>>>Vysledkem analytickych vypoctu je "cosi", na co se zapomnelo pri datove
analyze.
>>>Proto to chybi ve "standardnich" tabulkach a zada si to "temporary".
>>>...
>>>Cim lepsi datovy navrh, tim mensi potreba vytvaret pomocne tabulky.